<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en-us">
<head>
<title>COMP60370: Architecture</title>
<!-- metadata -->
<meta name="generator" content="S5">
<meta name="version" content="S5 1.1">
<meta name="presdate" content="20070921">
<meta name="author" content="Bijan Parsia">
<meta name="company" content="The University of Manchester">
<!-- configuration parameters -->
<meta name="defaultView" content="slideshow">
<meta name="controlVis" content="hidden">
<!-- style sheet links -->
<link rel="stylesheet" href="ui/default/slides.css" type="text/css" media="projection" id="slideProj">
<link rel="stylesheet" href="ui/default/outline.css" type="text/css" media="screen" id="outlineStyle">
<link rel="stylesheet" href="D:\Users\Chris\Documents\Uni Work\Third Year\3rd Year Project\Print CSS Files\print_pdf.css" type="text/css" media="print" id="slidePrint">
<link rel="stylesheet" href="ui/default/opera.css" type="text/css" media="projection" id="operaFix">
<!-- S5 JS -->
<script src="ui/default/slides.js" type="text/javascript"></script>

</head>
<body dir="ltr">
<div class="layout">
  <div id="controls">
    <!-- DO NOT EDIT -->
  </div>
  <div id="currentSlide">
    <!-- DO NOT EDIT -->
  </div>
  <div id="header"></div>
  <div id="footer">
    <h1>18-02-2008</h1>
    <h2>COMP60370: Architecture</h2>
  </div>
</div>
<div class="presentation">
  <div class="slide">
    <h1>COMP60370<br>
      Architecture<br>
    </h1>
    <h2>Bijan Parsia</h2>
    <b>http://cs.man.ac.uk/~bparsia/comp60370/arch.html</b>
    <h2>{bparsia@cs.man.ac.uk} </h2>
  	<input type="button" onClick="generateRef()"
value="How many input elements?" />
  </div>
  <div class="slide">
    <h1>Stepping back<br>
    </h1>
    <ul>
      <li>Thus far, focus on a document format (HTML)</li>
      <ul>
        <li>Uncoordinated authoring</li>
        <ul>
          <li>Validation</li>
        </ul>
        <ul>
          <li>Error handling</li>
        </ul>
        <li>Universality and longevity</li>
        <ul>
          <li>Separation of structure and style</li>
        </ul>
        <ul>
          <li>Semantic markup</li>
        </ul>
        <li>(We've barely mentioned hypermedia!)</li>
      </ul>
      <li>Still need:</li>
      <ul>
        <li>The Web</li>
        <li>Applications</li>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>The Client<br>
    </h1>
    <ul>
      <li>What are the phases?</li>
      <ul>
        <li>Retrieval</li>
        <li>Parsing&nbsp;</li>
        <li>Rendering</li>
        <li>Interaction</li>
      </ul>
      <li>What are the technologies?</li>
      <ul>
        <li>HTTP (and URI)</li>
        <li>Tag soup/HTML5 to DOM</li>
        <ul>
          <li>Could include some Javascript</li>
        </ul>
        <li>HTML, &nbsp;CSS &amp; Javascript</li>
        <li>HTML, Javascript &amp; CSS</li>
      </ul>
      <ul>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>The Server</h1>
    <ul>
      <li>What are the phases?</li>
      <ul>
        <li>Parse request</li>
        <li>Gather response components</li>
        <li>Massage components</li>
        <li>Respond</li>
      </ul>
      <li>What are the technologies?</li>
      <ul>
        <li>HTTP (and URIs)</li>
        <li>Arbitrary</li>
        <li>Arbitrary</li>
        <li>HTTP</li>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Web differences</h1>
    <ul>
      <li>Compare with:</li>
      <ul>
        <li>Chat</li>
        <li>Mail</li>
      </ul>
      <li>Some key features</li>
      <ul>
        <li>Hyperlinks</li>
        <li>Distributed documents/data units</li>
        <ul>
          <li>Crosses organization boundaries</li>
          <ul>
            <li>Uncoordinatedly</li>
          </ul>
          <li>Seamless experience</li>
          <ul>
            <li>Links take you anywhere</li>
          </ul>
        </ul>
        <li><i>Data</i> addressing</li>
        <ul>
          <li>Not mailboxes/users</li>
        </ul>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Explaining the Web</h1>
    <ul>
      <li>What needs explaining?</li>
      <li>What sorts of explanation?</li>
      <li>Who needs the explanations?</li>
      <li>What is done with these explanations?</li>
    </ul>
  </div>
  <div class="slide">
    <h1>One Sort of Explanation</h1>
    <ul>
      <li>What needs explaining?</li>
      <ul>
        <li>The "success" of the Web</li>
        <li>Why HTTP + URI + HTML "works"</li>
      </ul>
      <li>What sorts of explanation?</li>
      <ul>
        <li>"Web architecture" "supports"</li>
        <ul>
          <li>Web scale</li>
          <li>Web growth</li>
        </ul>
      </ul>
      <li>Who needs the explanations? (Purportedly)</li>
      <ul>
        <li>Protocol and format designers</li>
        <li>Application builders (and framework builders)</li>
      </ul>
      <li><a href="http://www.w3.org/TR/webarch/">Web architecture</a> and <a href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm">REST architectural style</a></li>
    </ul>
  </div>
  <div class="slide">
    <h1>A Weak Explanation</h1>
    <ul>
      <li>Metcalfe's law</li>
      <ul>
        <li>The value of a network increases with the square of the (compatible) participants</li>
        <ul>
          <li>Some <a href="http://spectrum.ieee.org/print/4109">debate</a> on the <a href="http://simeons.wordpress.com/2006/07/26/metcalfes-law-more-misunderstood-than-wrong/">factor</a></li>
        </ul>
        <li>A corollary: large networks are expensive to abandon, thus hard to compete with</li>
        <li>(But what is the <a href="http://www.hyperorg.com/backissues/joho-jan19-01.html#reed">realizable</a> value?)</li>
      </ul>
      <ul>
        <li>(What about <a href="http://www.gladwell.com/1996/1996_06_03_a_tipping.htm">tipping points</a>?)</li>
      </ul>
      <li>"Metcalfe's
        Law provides much of the explanation of the success of the Web relative
        to earlier hypertext systems like HyperCard, Intermedia, and NoteCards.
        They were all much better than the Web and had features ten years ago
        that we are still sorely missing on the Web. But the Web was universal
        and the other systems were proprietary. You know who won." --<a href="http://www.useit.com/alertbox/990725.html">Nielson</a></li>
    </ul>
  </div>
  <div class="slide">
    <h1>A Weaker Explanation</h1>
    <ul>
      <li>[Knowledge representation (KR)] made sense but was of limited
        use on a small scale, but never made it to the large scale. This is
        exactly the state which the hypertext field was in before the Web. Each
        field had made certain centralist assumptions ... which prevented them
        from spreading globally....<b>The Semantic Web is what we will get if we perform the same globalization process to KR that the Web initially did to Hypertext</b>" -- <a href="http://www.w3.org/DesignIssues/RDFnot.html">Berners-Lee</a></li>
      <li><b>The essential property of the World Wide Web is its universality.</b> Like
        the Internet, the Semantic Web will be as decentralized as possible.
        Such Web-like systems ... provide benefits that are hard or impossible
        to predict in advance. Decentralization requires compromises: <b>the
        Web had to throw away the ideal of total consistency of all of its
        interconnections, ushering in the infamous message "Error 404: Not
        Found" but allowing unchecked exponential growth.&nbsp;</b>-<a href="http://www.sciam.com/article.cfm?id=00048144-10D2-1C70-84A9809EC588EF21&amp;print=true">-Berners-Lee et al</a><a href="http://www.useit.com/alertbox/990725.html"></a></li>
    </ul>
  </div>
  <div class="slide">
    <h1>Architecture</h1>
    <ul>
      <li>An abstract description of a system</li>
      <ul>
        <li>Abstraction hides details</li>
        <li>Layered architecture allows for different structures at each layer</li>
        <ul>
          <li>Asynchronous messaging on top of synchonous one</li>
        </ul>
        <li>Phased architecture allows for different structures at each phase</li>
      </ul>
      <li>Architecture describes</li>
      <ul>
        <li><i>elements</i> in <i>configurations</i> under <i>constraints</i> which have ("induce")&nbsp;<i>properties</i></li>
        <li>The properties are what we are trying to explain in terms of the architecture<i><br>
          </i></li>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Elements</h1>
    <ul>
      <li>Components</li>
      <ul>
        <li>Data processors</li>
      </ul>
      <li>Connectors</li>
      <ul>
        <li>Data bus</li>
      </ul>
      <li>Data</li>
      <ul>
        <li>Information transmitted across connectors and manipulated by components</li>
        <li>Components and connectors can be data (and vice versa)</li>
        <ul>
          <li>Easily seen in phased architecture</li>
          <li>E.g., A program is data for an interpreter; an interpreter is a program</li>
        </ul>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Configurations and properties</h1>
    <ul>
      <li>Configurations</li>
      <ul>
        <li>Arrangement of elements, or</li>
        <li>a set of constraints on component interaction</li>
        <ul>
          <li>e.g., permitted inputs, outputs, sources, and targets</li>
        </ul>
      </ul>
      <li>Properties</li>
      <ul>
        <li>Functional</li>
        <ul>
          <li>Computing payroll, sending email, etc.</li>
        </ul>
        <li>Non-functional</li>
        <ul>
          <li>Scalability, extensibility, reliability</li>
        </ul>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Architectural Style</h1>
    <ul>
      <li>An abstract description of architectures</li>
      <ul>
        <li>"A coordinated set of architectural constraints"</li>
        <li>Elements are characterized in terms of roles or features</li>
        <li>Configurations are loosely constrained</li>
        <ul>
          <li>E.g., &nbsp;pipe and filter <i>style</i> constrains the "shape<i>" </i>of the connectors (i.e., linear, stateless, irreversible);&nbsp;</li>
          <li>particular systems may have an architecture that conforms to this style</li>
          <ul>
            <li>but they'll also select specific filters and connection types</li>
          </ul>
        </ul>
      </ul>
      <li>"Induction" of properties may be foiled</li>
      <ul>
        <li>by specifics of the realization</li>
        <li>dangerous fuzziness here</li>
        <ul>
          <li>consider scalability vs. worst case complexity</li>
        </ul>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Desirable (NF) Properties</h1>
    <ul>
      <li>Performance</li>
      <ul>
        <li>User perceived&nbsp;(esp, latency, see World Wide Wait and completion)</li>
        <li>Network efficiency (esp. <i>cost</i>)</li>
      </ul>
      <li>Scalability</li>
      <li>Simplicity</li>
      <li>Modifiability</li>
      <ul>
        <li>Evolvablity, extensibility, customizability, configurability, resuability, (and I say) portability</li>
      </ul>
      <li>Visibility</li>
      <ul>
        <li>I.e., to mediators for performance (caching) or security (firewalls)</li>
      </ul>
      <li>Reliability</li>
    </ul>
  </div>
  <div class="slide">
    <h1>Explanada</h1>
    <ul>
      <li>Network-based Applications</li>
      <ul>
        <li>Network-Based (according to Fielding)</li>
        <ul>
          <li>Interaction between components by message passing</li>
        </ul>
        <ul>
          <li>The network interactions are <i>perceptible</i></li>
          <ul>
            <li>Contrasted with <i>distributed</i> systems</li>
            <ul>
              <li>Where the network is <i>inperceptible</i></li>
            </ul>
          </ul>
        </ul>
        <li>Application</li>
        <ul>
          <li>Concerned with "business logic"</li>
          <li>Typically heavily end-user oriented</li>
        </ul>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>The Web as Application</h1>
    <ul>
      <li>The Web as a "Shared Information Space" (SIS)</li>
      <li>Requriements</li>
      <ul>
        <li>Low-Entry Barrier</li>
        <ul>
          <li>For authors, readers, publishers, tool/infrastructure builders</li>
          <li>At the start, similar for every category</li>
          <ul>
            <li>As things grew, barriers shifted</li>
          </ul>
        </ul>
        <li>Extensibility</li>
        <ul>
          <li>The Web changed frenetically</li>
          <li>The Web <i>needs</i> to change</li>
        </ul>
        <li>Distributed Hypermedia</li>
        <li>Internet-scale</li>
        <ul>
          <li>Esp. uncoordination</li>
          <ul>
            <li>Positive <i>and</i> negative</li>
          </ul>
        </ul>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Some questions</h1>
    <ul>
      <li>Fielding says: "By its nature, user actions within a
        distributed hypermedia system requrie the transfer of large amounts of
        data from where the data is stored to where it is used. Thus the Web
        architecture must be designed for large-grain data transfer." pg. 68.</li>
      <ul>
        <li>Why the move from <i>amount</i> to <i>grain</i>?</li>
      </ul>
      <li>Is "anarchic scalability" actually a requirement?</li>
      <ul>
        <li>Could Google run the Web?</li>
        <li>What about large Walled Gardens (e.g., Facebook?)</li>
      </ul>
      <li>What about flash?</li>
    </ul>
  </div>
  <div class="slide">
    <h1>Style Derivation</h1>
    <ul>
      <li>Styles are sets of constraints</li>
      <ul>
        <li>Thus may be <i>composed</i></li>
        <li>Or, styles may be <i>derived</i> (from other styles)</li>
        <li>(Presumably, not <i>arbitrary</i> merged! <i>Coordinated</i> constraints, eh?)</li>
      </ul>
      <li>REST is a derived style:</li>
      <ul>
        <li>Client-server +</li>
        <li><b>Stateless</b> +</li>
        <li>Cache +</li>
        <li><b>Uniform Interface</b> +</li>
        <li>Layered System +</li>
        <li>Code-on-demand (for clients)</li>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>REST diagram</h1>
    <p align="center"><img alt="Fielding's made an amazingly obscure and fairly ugly diagram purporting to show the REST archtiectural style." src="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_style.gif" height="220" width="435"><br>
    </p>
  </div>
  <div class="slide">
    <h1>REST Derivation</h1>
    <p align="center"><img alt="Another diagram by Fielding showing the derivation of REST through the other styles, with properties induced at each step shown." src="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_derivation.gif" height="257" width="435"></p>
  </div>
  <div class="slide">
    <h1>Statelessness</h1>
    <ul>
      <li>Obviously, there is some sense of stateful interaction</li>
      <ul>
        <li>Browser histories and the back button</li>
        <ul>
          <li>But that's client side info</li>
          <li>And order is (more or less) arbitrary</li>
          <li>The <i>interaction</i> in question is the HTTP request/response</li>
        </ul>
        <li>Cookies</li>
        <ul>
          <li>Compare with web forms with hidden fields, or</li>
          <li>URIs with session info, or</li>
          <li>Typical search result pages</li>
        </ul>
      </ul>
      <li>Stateful interaction ties client and server (or can)</li>
      <ul>
        <li>Typically the connection is maintained</li>
        <li>Reconnect recovery is expensive</li>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Uniform Interface&nbsp;</h1>
    <ul>
      <li>The constraints on component interfaces:</li>
      <ul>
        <li>identification of resources</li>
        <li>resource manipulation via "representations"</li>
        <li>self-descriptive messages</li>
        <li>hypermedia is the engine of application state</li>
      </ul>
      <li>We can see this on the Web:</li>
      <ul>
        <li>URIs</li>
        <li>HTTP (GET, PUT, POST, DELETE)</li>
        <li>HTTP requests and responses</li>
        <li>HTML (esp. the <code>&lt;a&gt;</code> tag)</li>
      </ul>
      <ul>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>REST elements</h1>
    <ul>
      <li><a href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#tab_5_1">Data elements</a></li>
      <ul>
        <li>Resources, resource identifiers, representations, metadata</li>
      </ul>
      <li><a href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#tab_5_2">Connectors</a></li>
      <ul>
        <li>Clients, servers, caches, resolvers</li>
      </ul>
      <li><a href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#tab_5_3">Components</a></li>
      <ul>
        <li>User agent, origin server, proxy, gateways</li>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>What the heck is a resource?</h1>
    <ul>
      <li>"We do not limit the scope of what might be a resource. The term
        "resource" is used in a general sense for whatever might be identified
        by a URI. It is conventional on the hypertext Web to describe Web
        pages, images, product catalogs, etc. as &#8220;resources&#8221;. The
        distinguishing characteristic of these resources is that all of their
        essential characteristics can be conveyed in a message. We identify
        this set as &#8220;information resources.&#8221;"-- <a href="http://www.w3.org/TR/webarch/#id-resources">WebArch</a></li>
      <li>"The
        key abstraction of information in REST is a resource. Any information
        that can be named can be a resource: a document or image, a temporal
        service (e.g. "today's weather in Los Angeles"), a collection of other
        resources, a non-virtual object (e.g. a person), and so on. In other
        words, any concept that might be the target of an author's hypertext
        reference must fit within the definition of a resource. A resource is a
        conceptual mapping to a set of entities, not the entity that
        corresponds to the mapping at any particular point in time."-- <a href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1">Fielding</a></li>
    </ul>
  </div>
  <div class="slide">
    <h1>"More precisely..."</h1>
    <ul>
      <li>"...a resource&nbsp;<i>R</i> is a temporally varying membership function&nbsp;<i>MR(t)</i>, which for time&nbsp;<i>t</i> maps to a set of entities, or values, which are equivalent. The values in the set may be&nbsp;<i>resourse representations</i> and/or&nbsp;<i>resource identifiers</i>." -- <a href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1">Fielding</a></li>
      <li>"By design a URI identifies one resource." -- <a href="http://www.w3.org/TR/webarch/#id-resources">WebArch</a></li>
      <li>Anyone notice the vacuity?</li>
    </ul>
  </div>
  <div class="slide">
    <h1>Representations</h1>
    <ul>
      <li>Why a resource/representation split?</li>
      <ul>
        <li>Content negotiation (conneg) and generated content</li>
        <ul>
          <li>HTML and PDF <i>versions</i> of these slides</li>
          <li>JPEG or PNG or GIF or...</li>
        </ul>
        <li>Statelessness</li>
        <ul>
          <li>Representations (can) go stale</li>
          <li>If you have the thing itself, it cannot</li>
        </ul>
        <li>Modeling</li>
      </ul>
      <li>Why not?</li>
      <ul>
        <li>It gets a bit metaphysical</li>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Representation manipulation</h1>
    <ul>
      <li>HTTP core <a href="http://rest.blueoxen.net/cgi-bin/wiki.pl?HttpMethods">methods</a></li>
      <ul>
        <li>GET</li>
        <ul>
          <li>(Safely) Retrieve a rep</li>
        </ul>
        <li>PUT</li>
        <ul>
          <li>Update the resource</li>
        </ul>
        <li>POST</li>
        <ul>
          <li>Make a new "subordinate" resource</li>
        </ul>
        <li>DELETE</li>
        <ul>
          <li>"Delete" the resource</li>
        </ul>
      </ul>
      <li>GET and POST historically dominate</li>
      <ul>
        <li>GET safety critical</li>
      </ul>
      <li>Where do application specifics go?</li>
      <ul>
        <li>In the URI, messages, and server logic</li>
      </ul>
    </ul>
  </div>
  <div class="slide">
    <h1>Reading &amp; References</h1>
    <ul>
      <li><a href="http://www.w3.org/TR/html-design-principles/">HTML
        Design Principles</a></li>
      <li><a href="http://www.w3.org/People/Bos/DesignGuide/toc.html">An
        Essay on W3C's Design Principles</a></li>
      <li><a href="http://www.seas.upenn.edu/%7Egaj1/metgg.html">Metcalfe's Law and Legacy</a></li>
      <li><a href="http://blogs.zdnet.com/Apple/?p=1316">Google; AT&amp;T shocked by iPhone usage</a></li>
      <li><a href="http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-03.txt">HTTP/1.1</a></li>
    </ul>
  </div>
  <div class="slide">
  <h1>References</h1>
    <p id="references"> </p>
  </div>
</div>
</body>
</html>
